Hello everyone,

It is true that Java lacks some important language elements that Python does not.

I would like to add that Python, Javascript and Ruby are weakly typed languages (which a lot more important than the fact that they are interpreted, the interpreted / compiled with resulting binaries criterion can change anytime and no harm shall come to those who are using and developing these languages).

Java is not a weakly type language, meaning that it holds full knowledge of what things Are, and it does so at runtime.

Sure, it doesn't have properties, but still it is a different world. Java and Python are interchangeable only from a superficial and ignorant point of view.

Java is a whole lot more predictible than Python.
If one of your arguments that python is better than Java is that is enables programmers to use properties, and thusly make them believe they are setting a field when in fact they are calling a method, then we cannot be ignorant and must say that:

Anders Hejlsberg, is a real genius, who designed and/or created Delphi, C# and the .NET Framework.

Delphi was having properties while others didn't know what an Visual IDE is, when Visual Basic and Java didn't even exist.

Because Python is not predictible, and it's syntax does not even begin to describe the runtime behaviour, (you can only hope for certain values to be returned by certain methods) it is not simply Better than Java.
It simply makes a different compromise.

Sure there are languages that were simply designed wrong and they long ago left the battlefield and cannot evolve (being stuck).
It is indeed the case of Java, which because of bad moves and childhood sins is now stuck whereas C# is evolving in the core and in the API and is wonderfull to note that, although it is a strongly typed, imperative language it is now gaining the benefits of weakly typed languages (it will soon allow C# programmers to do what Python programmers are doing and not care about type casting anymore for instance) and functional languages (like F#, Prolog, etc) without having to make any compromises.

That's something. Lines of Code count and syntactic sugar are an ignorant way to try to diplomatically invalidate a programming language.

It is true that I dislike C++ and Java. But still in comparison to Java, and from a professional point of view, an enterprise application would be simply handicaped if it were written in Python.

There are many things more important than LOC count in application design and development.

Python has no (real) classes. All things are Hashtables and are therefore uncertain. I'm not saying it's bad, it's just the other side of Python. Everyone makes compromises.

Python may have default values for constructors but on the other hand it has no overloading. It cannot have that since there is no early or late binding between caller and callee, based on a callee synatically (development time) provided identifier.

It does not have many things which in turn allows it to develop other abilities.

My point is: Java and Python are not interchangeable if you know what you want to do. If you're just a kid who was amazed during childhood by computer games and then started to learn programming in a rather random way, and you don't have a clue of what you're doing, then they are interchangeable since you don't know exactly what fits you, what are the things you can do without and what are those that you need.

Then there's the synergistic effect. Sometimes you are hired for a certain project, or are told to use a certain language.

Ok, see ya,
Nice video although there are waay to many conclusions based on arguments that are only partially true, either in quantity or in quality (by that I mean, not always true, it depends on the context, or it is an argument that is true but is not a causal input of the conclusion).

Thank you,
Eduard Dumitru

Its wonderful video and i am very glad to see this video in this site, i felt happy for this clarity and good knowledge presented in this video.
============================
steve
[url=http://www.localdrugrehab.com]Drug Rehab[/url]

I tried python and it is dirt-easy to read.

Thats exactly what I love about it,
YOU CAN READ IT.

I worked at intellon.com and they do embedded C++ with nucleus. What a fuc-ing mess. Only one programmer there could figure it out. What job security!

Thats when I learned that NASA used python and then I looked at python code samples, and hot-damn you can actually read it! I got a networking package named scapy.py to work in a day to do extensive network testing!

C++ is the write-only language for sure. You cant modify it unless you authored it. I wonder if UML will help in maintaining C++, but its not there yet.

My only question is: Do you think it will end up in embedded devices? Sean, you mentioned that you use python on web, but I need embedded compilers. I don't know how hard to push for embedded compilers for python to augment/replace C++.

Thanks for publishing!

I'm not addicted to Java. It works well for some things (and some clients) and not so well for others. However, I think your comparison is a bit off.

In particular, the benefit of encapsulation is like the benefit of defensive driving. You shouldn't need to do it, but your life is possibly better (longer?) when you do. Few people intentionally cause traffic accidents and yes, we're all consenting adults on the road too.

In any system big enough to require a team of 2 or more programmers, encapsulation helps to prevent the _accidental_ creation of defects. You thoughtfully define your interface and then implement it. No chance of someone making a mistake by going around it.

Further, your complaint that clients of the Java class would have to be updated also misses the point. If the interface changes, its clients ought to be reviewed! A client-incompatible change is a signal that the interface has changed enough that the client should get a review.

In your example, you added an exception that's thrown when the input is invalid. I think Java happens to do a great job at signalling that the client code isn't expecting that exception and thus should be reviewed.

Ultimately, on a large project, you don't always know who's using the class and how. Encapsulation (and strong typing) help by letting the class designer specify an interface. When that's done well, mistakes across class boundaries are few.